• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The present invention relates to a method of peer-to-peer exchange, of the Diffie-Hellmann type, authenticated by means of a block chain for storing smart contracts in the distributed register. The key exchange is then performed by means of such a contract in which the peers are declared. Each peer calls the contract and the latter records their portfolio addresses. On the call of the recipient peer, and after having verified the portfolio address of the latter, the contract gives him the public key generated by the sending peer.
    公开号:FR3076420A1
    申请号:FR1763394
    申请日:2017-12-29
    公开日:2019-07-05
    发明作者:Christine Hennebert
    申请人:Commissariat a lEnergie Atomique CEA；Commissariat a lEnergie Atomique et aux Energies Alternatives CEA；
    IPC主号:
    专利说明:

    KEY EXCHANGE METHOD BY INTELLIGENT CONTRACT DEPLOYED ON A BLOCK CHAIN
    DESCRIPTION
    TECHNICAL AREA
    The present invention relates generally to cryptography and more particularly to the generation of a secure channel between peers by means of a secret key. It also relates to the blockchain technique.
    PRIOR STATE OF THE ART
    The generation of a secure channel in remote devices, also called “peers” in the following, supposes the sharing of a secret key between these devices. This sharing can be achieved by manual distribution of keys, prior to any communication on the channel, or by means of a Diffie-Hellmann type key exchange protocol using an asymmetric cryptosystem. Remember that in a Diffie-Hellman type key exchange protocol, each remote device has an asymmetric pair of keys (private key, public key). The private key of a sending device is kept secret by the latter and is in particular never disclosed to the receiving device. It is used to encrypt or sign messages and to identify the sending device. On the other hand, the public key is known to the recipient device and is used to decrypt messages or to verify the signature of the sending device. The purpose of the key exchange protocol is to allow, from public elements of a cryptosystem exchanged on an insecure channel, each remote device to independently calculate the same secret key which will be used to establish a secure channel between them .
    When the cryptosystem is based on an elliptic curve E (f) defined on a finite field F and characterized by the domain parameters (q, a, b, G, n, h) where q is the number of elements of the body, a, b are the parameters of the elliptic curve, G is a generator point, n is the order of G in the additive group E (P), h ------- is the n
    cofactor of G in this group, is the order of the group £ (F ). Each remote device can choose a private key sk from among the integers [1, zz - 1], the corresponding public key being given by the coordinates of the point Pk = sk.G. It is recalled that to search, s £ starting from Pk amounts to looking for a solution to the problem ECLDP (Elliptic Curve Discrete Logarithm Problem), currently impossible to solve in polynomial time.
    If Alice and Bob are the two peers corresponding to the two remote devices, a Diffie-Hellmann key exchange protocol using an elliptical cryptosystem (ECDH protocol) can be described by the following steps:
    Alice chooses an integer a which will remain secret, calculates the ephemeral public key, P a = aG, and transmits it to Bob.
    Similarly, Bob chooses an integer b which will remain secret, calculates the ephemeral public key, P b = bG, and transmits it to Alice.
    When P b is received , Alice calculates aP b = ab.G.
    On receiving P a , Bob calculates bP a = ba.G.
    Alice and Bob now share a secret element consisting of a point on the elliptical curve, ab.G. They can for example apply a hash function, previously agreed between them, to one of the coordinates of the point in question to obtain a symmetric session key with which they encrypt the data on the channel.
    An important limitation of the above key exchange protocol is that it is not immune to a Man-ln-the-Middle attack. Indeed, an attacker, Eve, can intervene between Alice and Bob, make Alice believe that she is trading with Bob and Bob that he is trading with Alice. By implementing the protocol described above, Eve chooses a first integer x and shares a first secret element axG with Alice, then chooses a second integer y and shares a second secret element byG with Bob. Eve can thus create a first secure channel with Alice and a second secure channel with Bob. When Alice believes she is transmitting data securely to Bob, she is actually providing it to Eve.
    Conversely, when Bob believes he is transmitting data securely to Alice, he is in fact also transmitting it to Eve.
    A known solution to remedy this type of attack is to identify the issuer of each public key. Thus, Alice transmits to Bob not only her ephemeral public key P a = aG but also a digital signature of P a , signed with her private key (for example by means of an ECDSA algorithm). Bob must then have Alice's public key to verify the signature in question. If the verification is positive, it means that the ephemeral public key was indeed issued by Alice and not a third party. Of course, conversely, Bob transmits to Alice his ephemeral public key P b = bG accompanied by the signature of P b by means of Bob's private key, and Alice proceeds to verify this signature using the public key of Bob to authenticate the origin of the ephemeral public key.
    This solution is however only partially satisfactory insofar as the transmission of the public key from Alice to Bob (or that from Bob to Alice) on an insecure channel is itself likely to be the subject of a "Man-in-theMiddle" attack. In order to link the public key of an issuer with its identity, we use a digital certificate (in X.509 format or implicit certificate, for example) issued by a certification authority. As a result, the Diffie-Hellman protocol requires the presence of a trusted third party to be robust to “Man-in-theMiddle” attacks.
    In order to avoid resorting to a trusted third party and in particular to a centralized certification authority, it was proposed in the article by P. McCorry et al. entitled “Authenticated key exchange over Bitcoin”, published in 2015 in Chen L., Matsuo S. (eds) Security Standardization Research. Lecture Notes in Computer Science, vol 9497. Springer, to use a peer identification technique based on the properties of the Bitcoin blockchain. It is recalled that a block chain is a distributed and secure register of all the transactions carried out since the chain was started. A complete introduction to the Bitcoin blockchain can be found in the work by A.M. Antonopoulos entitled "Mastering Bitcoin" published in 2015 by O'Reilly editions.
    Fig. 1 represents a key exchange method authenticated by a blockchain as described in the above-mentioned article.
    Before exchanging keys, we assume that Alice and Bob each independently generated a private key (noted a for Alice and b for Bob) and, from the corresponding public key (P a = aG for Alice and P b = bG for Bob), an ephemeral wallet address (noted @wallet_a Alice for Alice and @wallet_b Bob for Bob). Ephemeral addresses will only be used for transactions supporting this exchange. The respective portfolios of Bob and Alice are also assumed to be credited with sufficient cryptocurrency.
    Alice forms in 110 a transaction T a and this is broadcast to the nodes of the Bitcoin network. After being validated, incorporated into a block and confirmed by mining, it becomes part of the distributed ledger. Similarly, Bob forms in 120 a transaction T b and this is broadcast step by step to the nodes of the network.
    Generally, a transaction represents a transfer of cryptocurrency units from one entry (or several entries) to one exit (or to several exits). A transaction is denominated in terms of UTXO (Unspent Transaction Output), each UTXO representing an amount not spent by its owner and being locked by a locking script. To be able to spend a UTXO, the owner must identify himself by presenting cryptographic elements to the UTXO (generally the public key and a signature generated from the corresponding private key) in the form of an unlocking script. If the items presented in the unlock script meet the conditions specified in the lock script, the transaction is committed. Note that in Bitcoin, the most commonly used unlock script is Pay-to-Public-Key-Hash (P2PKH) and the lock script is scriptSig.
    The transaction T a formed by Alice includes as input a reference to a UTXO held at the wallet address @wallet_a Alice as well as an unlocking script (represented by a key). This unlock script contains the ephemeral public key of Alice, P a and a signature of this public key (more precisely of the transaction in which the public key P a is substituted for the unlock script, the transaction then being doubly hashed) at using the corresponding private key, a.
    The transaction T a includes as output the recipient's wallet address (Bob), i.e. @wallet_b Bob as well as a locking script (represented by a padlock in the figure) that Bob can unlock by providing, via an unlocking script , the cryptographic elements (public key and signature) satisfying the conditions set in the locking script. This transaction output creates a UTXO (@wallet_b Bobmontant) at Bob's ephemeral wallet address. Alice's ephemeral wallet address was also indicated at the output so that Alice could recover the balance of the transaction from her wallet (creation of a UTXO in Alice's ephemeral wallet).
    Similarly, the transaction T b includes as input a reference to a UTXO held at the wallet address @wallet_b Bob, as well as an unlocking script containing the ephemeral public key of Bob, P b , and a signature of this public key using the corresponding private key b.
    At the output, the transaction T b includes at the output the ephemeral wallet address of Alice @wallet_a Alice as well as a locking script (represented by a padlock in the figure) that Alice can unlock by providing the cryptographic elements satisfying the conditions set in the lock script. This output creates a UTXO (@wallet_a Alice-Amount) to Alice's ephemeral wallet address. A second exit is planned to recover the balance in the form of a UTXO at Bob's ephemeral wallet address.
    The amounts of UTXO @wallet_a Alice-amount and @wallet_b Bob-amount can be chosen equal to balance the exchange.
    Once the transactions T a and T b have been validated, recorded in the block chain and confirmed by mining, Alice (resp. Bob) scans the distributed register in search of the transaction sent by Bob (resp. Alice). Alice retrieves in the entry part of T b the ephemeral public key P b from Bob and, conversely, Bob recovers in the entry part of T a the ephemeral public key P a from Alice. Alice then calculates aP b = abG and Bob bP a = baG: Alice and Bob therefore have the shared secret key abG.
    The auditability of the distributed register allows all users (nodes) to verify that the ephemeral public keys used in this exchange have never been used before, that the public key P a belongs to Alice (more precisely is linked to the Alice's ephemeral wallet address) and that the public key P b belongs to Bob (more precisely is linked to Bob's ephemeral wallet address). Thus, the exchange of keys between Alice and Bob can be authenticated by the blockchain, without the intervention of a trusted third party.
    However, the systematic generation of ephemeral wallet addresses with each key exchange can prove to be complicated to manage and costly in terms of computing resources for the remote devices hosting these wallets.
    An object of the present invention is therefore to propose a method of exchanging keys between peers, authenticated by blockchain and therefore without recourse to a trusted third party, and which does not require the generation of ephemeral portfolios.
    STATEMENT OF THE INVENTION
    The present invention is defined by a method of exchanging keys between a first user and a second user of a chain of transaction blocks, the block chain being adapted to store smart contracts, each user having an address of wallet enabling it to send and receive transactions, the block chain storing a smart contract comprising:
    a first function (Fct A) having as argument at least one public key and which, when called by a user, stores the wallet address of the user who calls it as well as the public key as argument;
    a second function (Fct B) having as argument at least one public key and which, when called by a user, verifies that the wallet address of the user who calls it is that of an authorized user for the exchange and, in this case, stores the public key as an argument;
    a third function (Fct C) comprising a first instruction verifying that the wallet address of the user who calls it is indeed that stored by the first function and in this case returning to the user the public key stored by the second function, and a second instruction verifying that the wallet address of the user who calls it is indeed that stored by the second function and returning in this case to the user the public key stored by the first function; and that (i) the first user generates a first ephemeral private key (a) and a corresponding first ephemeral public key (P a ) by means of an asymmetric cryptosystem;
    (ii) the second user generates a second ephemeral private key (b) and a corresponding second ephemeral public key (P b ) by means of said asymmetric cryptosystem;
    (iii) the first user forms a first transaction (T A ) containing the first ephemeral public key and transmits it to the address of the smart contract, the address of the wallet of the first user as well as the first ephemeral public key then being stored in the smart contract, the block containing the smart contract then being mined;
    (iv) the second user forms a second transaction (T B ) containing the second ephemeral public key and transmits it to the address of the smart contract, the address of the wallet of the second user as well as the second ephemeral public key then being stored in the smart contract, the block containing the smart contract then being mined;
    (v) the first user forms a request in the form of a third transaction and sends it to the address of the smart contract, the second instruction of the third function of the smart contract then returning the second ephemeral public key;
    (vi) the second user forms a request in the form of a third transaction and sends it to the address of the smart contract, the second instruction of the third function of the smart contract then returning the first ephemeral public key;
    (vii) the first user calculates the product of the first ephemeral private key (a) with the second ephemeral public key (P b ) and the second user calculates (232) the product of the second ephemeral private key (b) with the first ephemeral public key (P a ) to generate a common secret key (k ab ).
    The first function of the smart contract preferably comprises as second argument the wallet address of the user authorized for the exchange and the first transaction transmits the wallet address of the second user as a second argument to the first function.
    Advantageously, to balance the costs, when the smart contract returns the first ephemeral public key to the second user or the second ephemeral public key to the first user, the smart contract returns to the first and second users half the amount indicated respectively in the first and second transactions.
    The smart contract advantageously includes a fourth function (Fct timeout) allowing the first user to terminate the smart contract if the second user has not transmitted the second transaction to the smart contract within a predetermined time (timeout) after the first user has transmitted the first transaction to the smart contract.
    The blockchain can be for example Hyperledger or Ethereum.
    In the case of Ethereum, one of the first, second, third and fourth transactions may include a parameter (STARTGAS) fixing the maximum complexity that the execution of the transaction is authorized to consume as well as a cost to be paid in terms of complexity (GASPRICE).
    BRIEF DESCRIPTION OF THE DRAWINGS
    Other characteristics and advantages of the invention will appear on reading a preferred embodiment of the invention, made with reference to the attached figures among which:
    Fig. 1, already described, schematically represents an exchange of keys between peers, authenticated by a block chain, according to a method known from the state of the art;
    Fig. 2 schematically represents an exchange of keys between peers, authenticated by an intelligent contract deployed on a blockchain, according to an embodiment of the invention.
    DETAILED PRESENTATION OF PARTICULAR EMBODIMENTS
    The idea underlying the present invention is to use a blockchain in which it is possible to record intelligent contracts, also called autonomous contracts or smart contracts. An example of such a blockchain is Ethereum. Another example of such a blockchain is Hyperledger.
    A smart contract is a program that is deployed (i.e. stored) in the blockchain and can be executed by any node on the network. Generally speaking, a smart contract can store data, send and receive payments, store an amount in cryptocurrency (ether in Ethereum), and execute actions autonomously and decentralized like a software agent. Typically, a smart contract checks if a number of entry conditions are met and, if so, runs automatically to provide a coded result in the contract.
    The smart contract in question here is responsible for authenticating the parties and providing them with the public keys accordingly.
    Fig. 2 schematically represents an exchange of keys between peers, by means of an intelligent contract deployed on a block chain, according to an embodiment of the invention.
    It is assumed that a first user (or first peer), Alice and a second user (or second peer) Bob each have a wallet address, i.e. @wallet_Alice for Alice and @wallet_Bob for Bob, and that they have communicate these addresses for example in the form of QR code, prior to the execution of the smart contract. In addition, Alice will have generated (in 201) a private key a and an ephemeral public key P a = aG by means of a cryptosystem on an elliptical curve. Likewise, Bob will have generated (in 202) a private key b and an ephemeral public key P b = bG using the same cryptosystem. Alice and Bob can more generally use an asymmetric cryptosystem to generate their pairs of private and public keys.
    The structure of the smart contract was represented in 250. It includes a first function Fct A, having as argument at least the ephemeral public key of a first peer (Alice). It can also include as argument the address of the portfolio of the second peer (Bob). This first function, when called, stores the wallet address of the peer calling it as well as its ephemeral public key. It also stores the wallet address of the second peer if it is passed to it as an argument.
    The smart contract includes a second function Fct B, having as argument at least the public key of the second peer (Bob). It can also include as argument the wallet address of the first peer (Alice). This second function, when called, stores the address of the peer calling it as well as its ephemeral public key. It also stores the address of the first peer if this is passed as an argument.
    In order to define the contracting parties, Fct A will include as an argument the address of the portfolio of the second peer or Fct B will include as an argument the address of the first pair, these two situations not of course being mutually exclusive .
    When the first function Fct A includes as argument the wallet address of the second peer, the function Fct B verifies that it is indeed called by this wallet address before storing the ephemeral public key which is supplied to it as argument.
    Conversely, when the second function Fct B includes as argument the wallet address of the first peer, the first function Fct A verifies that it is indeed called by this wallet address before storing the public key which is supplied to it as argument.
    The smart contract includes a third function, Fct C, whose purpose is to verify the identity of the parties who call it and to transmit the public keys according to the conditions of distribution provided for in the contract. In this case, the function Fct C contains a first instruction indicating that, if it is called by the wallet address of the first peer, it returns the ephemeral public key of the second peer. Similarly, it contains a second instruction indicating that, if it is called by the wallet address of the second peer, it returns the ephemeral public key of the first peer.
    Finally, advantageously, the smart contract contains a fourth Fct timeout function. If after a predetermined time, timeout, after the first peer (Alice) has registered its ephemeral public key by calling the first function, the second peer (Bob) has not yet called the second function to remove this key ephemeral public, the first peer can call the Fct timeout function to end the execution of the contract and, if necessary, recover its stake. Conversely, if after a timeout after the second peer (Bob) has registered his ephemeral public key by calling the second function, the first peer (Alice) has not yet called the first function to remove this public key ephemeral, the second peer can call the Fct timeout function to end the execution of the contract and, if necessary, recover its stake.
    The key exchange process then proceeds as follows:
    In step 211, Alice forms a first transaction, T A , and transmits it to the address (of the first function) of the smart contract. This first transaction contains Alice's ephemeral public key, P a , and, in the illustrated case, Bob's wallet address (also called account address in Ethereum), @wallet_Bob. The first transaction is digitally signed by Alice using her private key. During the execution of the first function, Alice's signature is verified by the node which executes it. Alternatively, Alice's signature can be verified by the contract itself. The wallet address of the peer initiating the transaction, @wallet_Alice, the wallet address @wallet_Bob, as well as the ephemeral public key P a are recorded in the smart contract. The contract is then "undermined" to validate its change of state.
    In step 212, Bob forms a second transaction, T B , and transmits it to the address of the second function of the smart contract. This second transaction contains Bob's ephemeral public key, P b , and is signed by Bob using his private key. As before, the signature can be verified by the node which executes the contract or by the contract itself. The second function compares the wallet address from which the second transaction was issued, in this case @wallet_Bob, with the wallet address stored in the contract. In the event of identity, the ephemeral public key, P b , is recorded in the smart contract. The change of contract state is then validated by mining the block that contains it.
    Alice and Bob are then able to send, independently of each other, respectively in 221 and 222, a request in the form of a transaction to the address of the smart contract in order to execute the third function, Fct C, the smart contract. More specifically, Alice transmits a transaction T AC to the function Fct C and Bob independently transmits a transaction T BC to this same function.
    The Fct C function compares the wallet address at the origin of transaction 221 (resp. 222) with the wallet address stored in the contract, namely @wallet_Alice (resp. @Wallet_Bob). In case of identity, the smart contract returns the ephemeral public key P b to Alice as an argument (resp. The ephemeral public key P a to Bob).
    Alice then calculates in 231 the secret key aP b = abG from the ephemeral public key P b which she has just received from the intelligent contract. Bob does the same in 232, bP a = baG, from the ephemeral public key of Alice that he has just received. Alice and Bob thus share the secret key k ab = abG to secure a communication channel outside the blockchain, secure data confidentiality or even use it for authentication purposes.
    In the illustrated case, if Bob has not provided his ephemeral public key P b within a predetermined time, timeout, of which he was previously informed by an off-chain process, Alice can transmit a transaction to the fourth function Fct timeout to put end of contract.
    Preferably, the functions Fct A and Fct B are chargeable, in other words transactions 211 and 212 must transfer an agreed amount to the smart contract in order to be able to execute them. This precaution notably makes it possible to rule out denial of service attacks.
    In addition, this sum can be returned to the parties during the execution of the function Fct C, with the delivery of the public keys P a and P b . More precisely, it can be provided that when a party successfully calls Fct C and receives the public key of which it is the recipient, the contract returns to the parties half of their stake. Thus, each of the parties is notified when the public key that it registered in the contract has been given to the other party. The return of half the stake plays the role of an acquittal for the party concerned.
    Optionally, transactions 211-212, 221-222 can include a parameter setting the maximum complexity (STARTGAS parameter in Ethereum), in number of steps or clock cycles, that the execution of the transaction is authorized to consume as well as a cost to pay in terms of complexity (GASPRICE parameter in Ethereum). The addition of these parameters makes it possible to require each user to pay for the resources he consumes and therefore to fight against “denial of service” type attacks obtained by creating infinite loops.
    The second embodiment generalizes without difficulty to an exchange of keys between any number of peers so that they can in particular create between them, two by two, independent secure channels.
    To do this, Alice initiates the process and provides the function Fct A, in addition to its ephemeral public key, P a , with the parties involved in the smart contract in the form of a list of portfolio addresses.
    Each of the registered parties can then identify themselves to the smart contract and have the Fct B function executed to store their ephemeral public key in the contract.
    Finally, each party registered in the contract can execute the Fct C function and recover the public key from the other parties. From its own private key and public keys thus recovered, each party can calculate a secret key shared with another party.
    The table below gives an example of key exchange, using a smart contract, between four parties Alice, Bob, Charlie and Dave.
    It is noted that the smart contract makes it possible to generate six secret keys, each secret key corresponding to a communication channel between two parties to the contract.
    Alice Bob Charlie Dave shared keybP aabG aP c cP a ACG aP d dP a ADGbP c cP b BCGbP d dP b BDG cP d dP c CDG
    权利要求:
    Claims (7)
    [1" id="c-fr-0001]
    1. Method for exchanging keys between a first user and a second user of a blockchain of transactions, the blockchain being adapted to store smart contracts, each user having a wallet address allowing him to send and receive transactions, characterized in that the blockchain contains a smart contract comprising:
    a first function (Fct A) having as argument at least one public key and which, when called by a user, stores the wallet address of the user who calls it as well as the public key as argument;
    a second function (Fct B) having as argument at least one public key and which, when called by a user, verifies that the wallet address of the user who calls it is that of an authorized user for the exchange and, in this case, stores the public key as an argument;
    a third function (Fct C) comprising a first instruction verifying that the wallet address of the user who calls it is indeed that stored by the first function and in this case returning to the user the public key stored by the second function, and a second instruction verifying that the wallet address of the user who calls it is indeed that stored by the second function and returning in this case to the user the public key stored by the first function; and that (i) the first user generates (201) a first ephemeral private key (a) and a corresponding first ephemeral public key (P a ) by means of an asymmetric cryptosystem;
    (ii) the second user generates (202) a second ephemeral private key (b) and a corresponding second ephemeral public key (P b ) using said asymmetric cryptosystem;
    (iii) the first user forms (211) a first transaction (T A ) containing the first ephemeral public key and transmits it to the address of the smart contract, the address of the wallet of the first user as well as the first ephemeral public key being then stored in the smart contract, the block containing the smart contract then being mined;
    (iv) the second user forms (212) a second transaction (T B ) containing the second ephemeral public key and transmits it to the address of the smart contract, the address of the wallet of the second user as well as the second ephemeral public key being then stored in the smart contract, the block containing the smart contract then being mined;
    (v) the first user forms (221) a request in the form of a third transaction and sends it to the address of the smart contract, the second instruction of the third function of the smart contract then returning the second ephemeral public key ;
    (vi) the second user forms (222) a request in the form of a third transaction and sends it to the address of the smart contract, the second instruction of the third function of the smart contract then returning the first ephemeral public key ;
    (vii) the first user calculates (231) the product of the first ephemeral private key (a) with the second ephemeral public key (P b ) and the second user calculates (232) the product of the second ephemeral private key (b) with the first ephemeral public key (P a ) to generate a common secret key ^).
    [2" id="c-fr-0002]
    2. A key exchange method according to claim 1, characterized in that the first function of the smart contract comprises as second argument the wallet address of the user authorized for the exchange and that the first transaction transmits the address second user portfolio as second argument to first function.
    [3" id="c-fr-0003]
    3. A key exchange method according to claim 1 or 2, characterized in that, when the intelligent contract returns the first ephemeral public key to the second user or the second ephemeral public key to the first user, the intelligent contract returns to the first and second users half the amount indicated in the first and second transactions respectively.
    [4" id="c-fr-0004]
    4. Method for exchanging keys according to one of claims 1 to 3, characterized in that the smart contract comprises a fourth function (Fct timeout) allowing the first user to terminate the smart contract if the second user has not not pass the second transaction to the smart contract within a predetermined time (timeout) after the first user has transmitted the first transaction to the smart contract.
    [5" id="c-fr-0005]
    5. A key exchange method according to one of claims 1 to 4, characterized in that the block chain is Hyperledger.
    [6" id="c-fr-0006]
    6. A key exchange method according to one of claims 1 to 4, characterized in that the block chain is Ethereum.
    [7" id="c-fr-0007]
    7. A key exchange method according to claim 6, characterized in that at least one of the first, second, third and fourth transactions comprises a parameter (STARTGAS) fixing the maximum complexity that the execution of the transaction is authorized to consume as well as a cost to pay in terms of complexity (GASPRICE).
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3506557B1|2020-07-01|Method of key exchange via a smart contract deployed over a blockchain
    JP6799061B2|2020-12-09|Secure multi-party loss resistant storage and transfer of cryptographic keys for blockchain-based systems combined with wallet management systems
    RU2735439C2|2020-11-02|System and method for protecting information
    EP3010177B1|2018-07-25|Method for authenticating a client device with a server using a secret element
    US9036818B2|2015-05-19|Private key generation apparatus and method, and storage media storing programs for executing the methods
    EP3506556B1|2020-08-05|Method of authenticated key exchange via blockchain
    FR3004041A1|2014-10-03|METHOD AND DEVICE FOR ESTABLISHING SESSION KEYS
    FR3044499A1|2017-06-02|METHOD OF ESTABLISHING SECURE END-TO-END COMMUNICATION BETWEEN A USER TERMINAL AND A CONNECTED OBJECT
    CN109741068B|2021-04-27|Online banking cross-row signing method, device and system
    CN110414981A|2019-11-05|A kind of homomorphic cryptography method that supporting ZKPs and block chain transaction amount encryption method
    EP3398104A1|2018-11-07|Second dynamic authentication of an electronic signature using a secure hardware module
    EP2891268B1|2016-09-28|Group signature using a pseudonym
    EP3965361A1|2022-03-09|Data exchange between a client and a remote device, for example a secure module
    EP3654615A1|2020-05-20|Decentralised platform for improved privacy management
    EP3063898B1|2017-04-12|Signature with pseudonym for chip card
    Caubet Fernández2016|Secure identity management in structured peer-to-peer | networks
    FR3102024A1|2021-04-16|A method of managing a public key database, a method of authenticating public keys, and server and client devices implementing these methods
    WO2021133153A1|2021-07-01|Transaction signing with ergonomic addressing and compact encapsulation
    WO2019228853A1|2019-12-05|Method for establishing keys for controlling access to a service or a resource
    WO2017009067A1|2017-01-19|Method of secure delegation of expensive calculations for public key encryption algorithms
    WO2014199071A1|2014-12-18|Method and system for delegating a calculation of a bilinear coupling value to a calculation server
    FR2911024A1|2008-07-04|List e.g. electoral list, signature method for e.g. electronic voting field, involves supplying data by member of list, where data includes authentication data calculated based on formula, and implementing secret keys without revealing
    WO2011027071A1|2011-03-10|Cryptographic method for anonymously subscribing to a service
    FR2836768A1|2003-09-05|Digital signal formation having digital word generators with assistance/calculation systems producing intermediate respective result transmitting combination system/combining intermediate result.
    同族专利:
    公开号 | 公开日
    EP3506557A1|2019-07-03|
    EP3506557B1|2020-07-01|
    US11050563B2|2021-06-29|
    US20190207760A1|2019-07-04|
    FR3076420B1|2020-02-07|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US10361870B2|2017-09-14|2019-07-23|The Toronto-Dominion Bank|Management of cryptographically secure exchanges of data using permissioned distributed ledgers|
    US10778432B2|2017-11-08|2020-09-15|Wickr Inc.|End-to-end encryption during a secure communication session|
    CN108600272B|2018-05-10|2020-08-04|阿里巴巴集团控股有限公司|Block chain data processing method, device, processing equipment and system|EP3644548A4|2017-06-21|2021-02-24|Nippon Telegraph And Telephone Corporation|Key exchange system and key exchange method|
    US11128451B2|2019-03-25|2021-09-21|Micron Technology, Inc.|Remotely managing devices using blockchain and DICE-RIoT|
    CN110401494B|2019-08-30|2020-11-24|北京邮电大学|Quantum secure direct communication method irrelevant to measuring equipment on high-dimensional subspace|
    US10783082B2|2019-08-30|2020-09-22|Alibaba Group Holding Limited|Deploying a smart contract|
    WO2021053404A2|2019-09-10|2021-03-25|Currency Com Limited|Distributed blockchain-type implementations configured to manage tokenized digital assets and improved electronic wallets, and methods of use thereof|
    CN110730241B|2019-10-22|2022-01-25|河海大学常州校区|Global scale oriented blockchain infrastructure|
    法律状态:
    2018-12-31| PLFP| Fee payment|Year of fee payment: 2 |
    2019-07-05| PLSC| Search report ready|Effective date: 20190705 |
    2019-12-31| PLFP| Fee payment|Year of fee payment: 3 |
    2020-12-28| PLFP| Fee payment|Year of fee payment: 4 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1763394|2017-12-29|
    FR1763394A|FR3076420B1|2017-12-29|2017-12-29|METHOD OF EXCHANGING KEYS BY INTELLIGENT CONTRACT DEPLOYED ON A BLOCK CHAIN|FR1763394A| FR3076420B1|2017-12-29|2017-12-29|METHOD OF EXCHANGING KEYS BY INTELLIGENT CONTRACT DEPLOYED ON A BLOCK CHAIN|
    EP18215898.0A| EP3506557B1|2017-12-29|2018-12-26|Method of key exchange via a smart contract deployed over a blockchain|
    US16/234,020| US11050563B2|2017-12-29|2018-12-27|Method of exchanging keys by smart contract implemented on a blockchain|
    [返回顶部]